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Abstract 


Advantages of the standard external representation of LISP 
include its simple definition, its economical implementation and 
its convenient extensibility. These advantages have been gained 
by trading off syntactic variety for the rigidity of paren- 
thesized prefix notation. This paper describes an approach to 
increasing the available notational variety in LISP without 
compromising the above advantages of the standard notation. A 
primary advantage of the availability of such variety is the 
extent to which documentation can be incorporated into the code 
itself, decreasing the chance of mismatches between cod¢ and 
documentation. Тһе approach differs from that of MLISP*, which 
attempts to be a self-contained language rather than a notation 
available immediately on demand to the ordinary LISP user. A 
striking feature of a MACLISP implementation of this approach, 
the CGOL notation, is that any LISP user, at any time, without 
any prior preparation, and without significant compromise of 
storage or speed, can in mid-stream change to the CGOL notation 
merely by typing (CGOL) at the LISP he is presently using, even 
if he has already loaded and begun running his LISP program. 
Another striking feature is the possibility of notational 
transparency; a LISP user may ask LISP to read a file without 
needing to know the notation(s) used within that file. 


This report describes research done at the Artificial Intelligence 
Laboratory of the Massachusetts Institute of Technology. Support 
for the laboratory's artificial intelligence research is provided 
in part by the Advanced Research Projects Agency of the Department 
of Defense under Office of Naval Research contract N00014-75-C-0643. 
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HHHHHVARNINGHHUILH 

CGOL IS AN EXPERIMENTAL FACILITY. ALTHOUGH IT IS HOPED THAT THE 

. LANGUAGE WILL SETTLE DOWN FAIRLY SOON, IT IS AT PRESENT 100 EARLY TO 
COMMIT THE DESIGN TO STONE TABLETS. ALSO, SOME DIFFERENCES PRESENTLY 
EXIST BETWEEN THIS MANUAL AND THE IMPLEMENTATION. . THE KNOWN 
DIFFERENCES ARE DOCUMENTED IN SECTION 9. ` 


HHHHHCOME -ONHHHH oO І 
BUT DON'T LET THAT STOP YOU TRYING IT QUT. USER FEEDBACK WILL ВЕ 
MOST APPRECIATED. 


1. PHILOSOPHY 
1.1 Representational Nonsense 


LISP S-expressions ("abstract" objects in a domain that 
contains atoms and is closed under the pairing function CONS) require . 
an internal and an external representation ("concrete" objects). Тһе 
former is for the convenience of the programmer, the latter for that 
of the machine. The functions (READ) and (PRINT) provide maps betueen 
the tuo concrete representations. 


Ме use the term "LISP" principally to denote the abstract 
objects; out of respect for usage, however, we shal! also use it to 
denote "the" standard external representation, which varies mainly in 
detail from one implementation to the next. Ие rely on context to 
disambiguate these usages. We use "INT" to denote whatever internal 
representation obtains in a particular implementation. 


1.2 CGOL as an alternative external representation. 


This document describes an alternative external 
representation, CGOL, for those LISP S-expressions that encode 
procedural information. Тһе representation is modeled on McCarthy’ в 
M-expression notation; as such it has Smith and Enea's MLISP 1anguage 
as a predecessor. See section 8 for a discussion of similarities and 
differences between MLISP and CGOL. l 


In an environment that supports both CGOL and LISP external 
representation, ke envisage facilities for mapping between . 
' representations as diagrammed below: 
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READ - CGOLREAD P 
T рігітііт» РАСЕ ЕТЕ 1 
і CA T TTT TTT] жсшишпептш>» В 
PRINT i CGOLPRINT 


This diagram of course generalizes to any set of external 
representations. i Я 


71.3 Usage 


. { 
If LISP’s top-level, a cut-down version of which might be 

(PRINT (EVAL (READ))) , 
is replaced by ! 

(CGOLPRINT (EVAL (CGOLREAD))) the top level should пон expect CGOL 
“notation, and reply in like notation. (At present CGOLPRINT is 

implemented in MACLISP as PRINT, so the user must put up with LISP 
replies.) Е : 


Іп MACLISP, the function (CGOL) will set up your top and break 
levels as above. Both (CGOLREAD) and (CGOL) are autoloading. Thus if 
at any time while talking LISP you suddenly want or need to use 
CGOL notation, you need merely type (CGOL) at LISP and LISP. will then 
expect CGOL expressions. To revert to standard notation, type LISP . 
Because of the autoloading feature, no other action on your part is 
needed. This implies that you may have a mixture of CGOL and LISP 
programs in a single file, provided the appropriate heading 
information is given. The overhead of executing (CGOL): and LISP is 
negligible. | l | 


It is hoped at a later date to lambda-bind NOTATION to LISP, 
CGOL, MAPL or whatever, and to have top-level use NOTATION to choose 
: the appropriate versions of READ and PRINT. This will facilitate 
proper nesting of environments. An immediate application of such a 
scheme is to do all file reading with LISP as the default NOTATION for 
the duration of that file. Thus a user using notation Х can read а 
file without asking what notation it uses, and on exit from the file 
find that he is still using notation X. People preparing files need 
merely prefix non-LISP notation with the appropriate instruction to 
rebind NOTATION. 


1.4 Design Considerations. 


The tuo principles that serve respectively as lower and upper 
bounds on the choice of CGOL notation are: > 


(i) The notation should fairly match what the non-LISP 
community regards as a reasonable notation. In particular, users of 


e 


ALGOL, FORTRAN, PL/I etc, should not experience difficulty in guessing. 
the méanings of those constructs common to those languages, e.g. 
assignment, application, arithmetic and relational operations, and the 
more familiar control constructs. This requirement need not apply to 
constructs pecul iar to LISP, such as LIST, CONS, LAMBDA, EVAL, QUOTE 
and so on. 


(11) Тһе notation should restrict itself to being a notation for 
LISP abstract objects, and not try to be a full-blown programming 
language with its oun useful set of constructs, (This represents a 
point of departure from the MLISP philosophy? ) Useful constructs 
should be added to LISP via the same channels (modulo choice of 
notation) that are used regularly by all LISP users to augment LISP, 
e.g. (DEFUN ...) or its ССО equivalent. 


There is a tension betueen these tuo requirements that is at 
present not appreciated by the bulk of the computer science community. 
That tension is brought about by the tuo very different techniques for 
specifying the syntax of ALGÜL-like languages and the semantics of 
LISP programs. The former is phrase oriented, the latter is 
token oriented.  ("Phrase" and "token" may be replaced respectively by 
"non-terminal" and "terminal", to use the formal language 
terminology.) А typical syntax specification uses BNF, i.e. а 
context-free grammar, whereas LISP programs are specified in terms of 
the meaning of atoms, The rich non-terminal structure of, say, the 
syntax of ALGOL is replaced by a trivial non-terminal structure for 
LISP, namely al! non-atomic programs are of the form (FUNCTION 
ARGUMENTS) . 


Not all ALGOL-like languages are specified by their phrase 
structure. From time to time attempts are made to use the powerful 
macro facilities of assemblg languages to implement "higher level" 
languages. Since macros are identified by single tokens, they 
constitute a token oriented specification. A limitation of the 
approach is that the macro identifier must usually appear before its 
arguments. Also a macro interpreter that allows nested calls must be 
used. 

| | D" 2 
The CGOL notation upes a token oriented approach to fit 
comfortably with constraint, (ii), Unlike macro based approaches, а 
given token may have either zero or one argument preceding it, in 
addition to any number follouing it (suitably delimited). This gives 
rise to the familiar association problem, which ue deal with using 
Floyd’s notion of precedence functions? Each argument position of a 
token has an associated "binding power"; association is resolved in 
favor of the higher binding power. The binding power idea is due to 
Floyd, who called the binding powers “operator functions"; the term we 
use appears to have originated with CPL. The parsing algorithm we use 
differs from Floyd's in that ours is top-down whereas Floud's is 
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bottom-up. The original version of the CGOL parser was implemented at 
Stanford in July 1970; its use of binding powers was adapted soon after 
by Smith for the MLISP system* We discuss the details of the 
association problem in section 3. 


222. EXAMPLES OF CGOL EXPRESSIONS 


The following examples of CGOL expressions, together with the: 
effect of doing (PRINT (CGOLREAD)) on them (i.e. their LISP 
translations), are given below. To aid the eye we shall use upper 
case for LISP and lower case for CGOL. Note that CGOLREAD: demands an 
ALTMODE (not shown) after each CGOL expression. 


18 
(PLUS 1 1) 


(1, "2427, sin(.37%x+1)) 
(LIST 1 '(PLUS 2 2) (SIN (PLUS (TIMES .37 x) 1n) 


\x, ys l/sqrtGe2 + ТҮ 
(LAMBDA (X Y) (QUOTIENT 1 (SQRT (PLUS (EXPT X 2) (EXPT Y 2))))) 


sstatus(toplevel, ."print х; eval read’). 
(SSTATUS TOPLEVEL '(PROG2 (PRINT sx) (EVAL (READ)))) 


car т & car me cdrm 
(PROG2 NIL (CAR М) (RPLACA М (СОН M))) 


| *father’ of x = "'brother" of relative of y 
(PUTPROP X (GET (GET Y RELATIVE) "BROTHER) " FATHER). 


a(i,j) e 3 | 
(STORE (A І J) 3) i 


if i isnum and -j«i«j then TT else peint i 
(COND (САМ (NUNBERP I) (LESSP (MINUS J) I J)) (ABS 1)) (PRINT D) 


а. (bec) = (a. TT 
(EQUAL (CONS A (APPEND B C)) (APPEND (CONS A B) c 


for i in aeb do if 7«i«13 then return "In range" 
(МАРС (FUNCTION (LAMBDA (1) (COND ((LESSP 7 I 13) 
ng (RETURN. ”1/п/ /r/a/n/g/e))))) 
(APPEND A B)) l . 


f (x,y) (и, у, ы) (1) 
CCF xvi UV WT) 


if j remainder 6 isin !'(1 5) then print j 


262. 


else badlist e j . badlist 
<note: = ! is а no-op unary function that expects its a guieht 
in LISP notation» 
(COND (4MEMBER (REMAINDER J 6) '(1 5)) (PRINT J)) 
( (SETQ BADLIST {CONS J BADLIST)))) · : 


While (a;b) do c 
«a handy мау to put the stopping condition b. in the middie of 
.a loop body a;b> 

(DO NIL ((NOT (PROG2 А B))) C) 


define a "TO" b; if not a»b then а, ((atl) to b) 
(DEFUN TO (A B) (COND ((NOT (GREATERP А BJ) (CONS A (TO (PLUS A 1) B))))) 


3. GRAMMAR | 
| i 
А ССО expression is a string of sub-expressions and tokens. 
For example the expression "if aab then Ô else 1+1" has six 
constituents corresponding to the six items in the ' "construct" 
if a then b else c 
In this example those constituents are: 
the token "if" i 
_the sub-expression "asb" ! 4 
the token "then" ` mrt 
the sub-expression "8" 
the token "else" and 
the sub-expression "1+1". 
In turn, the sub- -expression "a=b" has three constituents: 
the sub-expression "a" 
the token "=" and 
'the sub-expression "b". 
And the sub-expression "a" has one constituent, the token "a", 


For those accustomed to BNF, the grammar of CGOL might look 
likes i 


«expression» ::» if «expression» then «expression» [else <expression>] 
«expression» :%- «expression»s«expression» 

«expression» ::« («expression») 

«expression» ::» «expression»; «expression» 


and so on. Since «expression» will.be the only non-terminal, the left l 
hand side of productions may be omitted without loss of. information. 
Substituting variables for «expression» , We can then write CGOL rules 
ast. i қ 


if а then b [else cl 
aab 
(а) 


ш 
с 


апа во оп. 


Ав they stand, such rules are ambiguous. Does asb;c mean | 
(a=b);c or as(b;c) ? The problem is that each of "=" and ";" could take 
b as its argument. Ме say that b associates uith the one that takes 
it as argument. Thus if "print a+b" means "print(a+b)", "a" has 
associated with "+" in preference to "print". Іп CGOL, all! such 
disputes are resolved by binding pouers, a sort of syntactic version 
of atomic valences. Thus if the right binding power (rbp) of "=" is 
10 and the left binding power (10р) of ";" is-1, then a-b;c ів read as 
(asb);c because the right hand argument slot of "s" pulis harder on b 
than does the ieft hand argument slot of ";" . {Ties are broken by 
associating to the left.) | | 

Left and right binding powers are completely independent. 
Each is relevant uhen the expression can have a sub-expression 
at the left As right hand ends pespect ively: Thus the left binding 
power of "car" is irrelevant because "car a" does not have a 
irt olia da ‘at the left.’ However, it has one at the right, so its 
right binding pouer is relevant. The opposite obtains for the suffix 
operator "isatom", which has a left binding power but no right binding 
power. In an expression like "if a then b else c", the right binding 
power applies to all three arguments even though only the last тау 
actually be fought over by another operator to its right. 


In addition to the left-right association problem there is the 
“dangling else" problem, named after an instance of the problem: does 
"if a then if b then c else d" mean "if a then (if b then с else d)" 

. or "if a then (if b then c) eise d" ? This problem is just a variant 
of the left-right association problem; the argument "else d" could 
associate with either the first or the second "if". In CGOL, ail such 
disputes are resolved by associating to the closer operator. (For 
those uho liked the atomic-valence analogy, imagine an inverse 
(square?) lau for distance holds.) l 


“Тһе above two rules deal with all ambiguities that might arise 
in the CGOL grammar viven below. | 

Тһе following table lists the explicitly defined CGOL 
constructs together with their translation into standard notation. 
Except where otherwise noted, a, b,...,Z denote CGOL. expressions and. 
A,B,...,Z their corresponding standard forms. The table has three 
columns, the CGOL. form, the left and right binding powers when 
relevant (only given once when they are the same, or alah only one is 
relevant), and the transtatjon. : 


uda 


(a) 8 A 


f(a,b,...,z) 20 (ҒАВ..: 2) . 
[а,Ы,..., 2) 8 (LIST AB ... C) 
---------QUOTING OPERATORS------- А 

‘a’ . 8 (QUOTE A) 

"a" {where a is a string) ' Jat 

?a (where a is a character) /а 


Ha (where а is апу CGOL token) А 
IA (where A is a LISP S-expr) А 


xad ied DECLARATIVE OPERATORS--------- 


Na, bsr.. z; f B (LAMBDA (AB... 2) F) : 
prog a,b,..,p; qirs..3z 8 (PROG (AB... P 0 В... 2) 
neu a,b,..,p; 20 2. (PROG (AB... P QR ... (RETURN 2)) 
special a,b,...,z 1 (DECLARE (SPECIAL АВ... 2)) 
--------- CONTROL OPERATORS-------- . 

eval a i (EVAL A) 

a;b 18 KPROG2 A B) 

ab . 18 (PROG2 NIL A 8) 

if a then b [else c] 2 (COND (А B) [(O1) 

return a uc (RETURN A) 

while a do b l 2 (DO NIL ((NOT A)) B) 

for i in ! do f 2 


(МАРС (FUNCTION (LAMBDA (1) F)) L) 


aofbec. 251 (PUTPROP B C A) 


aeb (а is atomic), 251 (SETQ A B) : 
х(а,б,...,2) ец 2261 (STORE (ХАВ... Z) Y) 
а of b . 25 24 (GET BA) 

a assoc b 25 24 (ASSOC A B) 

--------- LIST OPERATORS--------- 

a.b i 14 13 (CONS А 8) 

aeb 14 13 (APPEND A B) 

--------- RELATIONAL ОРЕНАТОН5-------- 

a=b 18 (EQUAL A B) 

anb | i 18 ' (NOT (EQUAL A B)) 

a eq b 18 |; {EQ A B) 

a«b«...«z . |. 18 (LESSP A B ... Z) 
а>р>...>2 18 7 (GREATERPA B ... 2) 

a isin b 18 (MEMBER: А B) 

а isatom ' 18 (ATOM A) 

a isnum 18 (NUMBERP A) 


din sin LOGICAL OPERATORS------- 
nota- 9 ТА 
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а and b 8 (AND A B) 


ao b- ШЕ 7 (OR A В) 
--------- ARITHMETIC OPERATORS------- 

. lal i 8 {ABS A) 
+a l 28 A 
a+b · 28 (PLUS А В) 
-a 20 - (MINUS A) 
a-b 20 (DIFFERENCE А В) 
axb "e 21 (TIMES A B) 
a/b ; 21 (QUOTIENT A B) 
a remainder b 21 . (REMAINDER А В) 
aserb 5 22. (ЕХРТ А 8) 
---------1/0 ОРЕНАТОН5------- 
print а. 2 (PRINT А) 
ргіпс а 2 (PRINC А) 
write а 2 (PROG2 (TERPRI) (PRINC A)): 
uread ab... z (a-z are tokens) (UREAD А B ... 2) 
uwrite ab... г | (UWRITE АВ... Z) 
ufile ab... 2 ШЕЦЕ AB... 2) 
load ab... 2 (а-2 are tokens) (FASLOAD AB... 2) 


newline (TERPRI) 


In addition to the above, CGOL "knows" about all the unary 
functions in LISP. It doés this by testing (ARGS token) when said 
token is undefined. Thus although "саг" does not appear іп the above 
table, ССО. knows that CAR is а LISP function with one argument. CGOL 
treats all such functions f as though they were defined as 


fa 25 (F A) 


When in doubt you can always drop back into LISP by using 
However, that should be rarely necessary - it is intended mainly 
for non-procedural items such as lists for doing MEMBER and ASSOC in. 
If you can’t recall the CGOL form of an expression (F AB... Z) you 
won’ Ё до wrong by writing fla,o,...,z). Thus if you forget the form 
"1+1", you can write "PLUS(1,1)" and it will translate correctly. 

By the same token, any LISP function not catered for in the above | 
table сап be written as "Ғ(а,б,...,2)", e.g. "sstatus(toplevel,ni I)". 


At first sight the binding pouers may seem a lot to learn. 
Houever, they have been chosen on the basis of the data types their 
operators take as arguments and return as results in order to minimize 
the need for parenthesization? If you want to use CGOL notation but 
don't want to have anything to do with binding powers, simply 
parenthesize every CGOL expression as though you were writing in 
LISP. However, if you omit all parentheses (apart from those needed 
in constructs of the form fí(a,b,...,z)) you will not often go wrong. 


Же 


Most often you will want parentheses for grouping іп arithmetic 
expressions when the default priority ranking (|| +- ж / mod жж) 
gives the wrong grouping, and when procedural expressions occur as 
arguments to non-procedural expressions, e.g. "if a then (b;c)", 
"(print a) + b", "ae(beread)«1" and the. like. 


Some operators һауе а right binding pouer one less than their 
left binding pouer. This is to make those operators right 
associative. For example, "a of b of c" is parsed as "a of (b of c)" 
(since oftener than not that's what uas intended), and "aebec" as 
"ae(bec)" (for efficiency). Ап interesting pair of right associative 
operators is ";" and "6". These are duals of each other. They both 
evaluate their arguments in the same order, but differ in the value 
they return: a&b returns a, a;b returns b. By making both of them 
right associative and giving them the same priority, they interact in 
an elegant way. Suppose you want to evaluate a,b,...,z and to return 
the value of k. Then the expression а;0;...К6...;2 has the desired 
effect. That is, follow every argument but the last with ";", except 
for the one you want the value of, which if it is not the last should 
be followed by "8". А common use for "&" is in tidying up after 
computing some value, e.g. "x & xe2" will set x to 2 and return the 
old value, "a e (b & bea)" will swap the contents of a and b without 
using a temporary variable, and so on. Note that all this is really a 
feature of LISP rather than of CGOL; however, the notation makes it 
easier to see at a glance the intent of what would be relatively 
difficult to follow in LISP. 


4. THE DEFINE FACILITY 


The CGOL analog of DEFUN is "define". In addition to allouing 
the user to attach a lambda expression to some functional property of 
an atom, it gives him some syntactic capabilities as well. 


The basic form is 
define «pattern» [,bp (,bpl]: body 
For акаврів; the following could serve as а definition оғ" 
define а "e" b, 14, 13; if a then car a. cdr a e b else ы” 
(For readability, one would normally put in more. parentheses than ме 
have here.) 
In this example, the pattern gives the rule for this operator, and the 
two numbers give the two binding powers. The body is what would 
normally appear as the body of a DEFUN. l 


At present the allowable forms of patterns are few in number. 
You may write а sequence of variables separated by one or more tokens 
in string quotes (letters inside string quotes must be capitalized -. 
this is the one place where a distinction is drawn between upper and 
lower case, in the sense that the reader maps all lower-case letters 
not in string quotes to upper-case before thinking about what they 
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mean). Тһе variables stand for CGOL expressions and the strings for 
tokens (recall that a CGOL expression is a sequence of sub-expressions 
and tokens). The sequence may start and end with either tokens or 
variables. l 


The first token in the pattern is called the operator, and the 
remaining tokens are called delimiters. The operator is said to have 
been defined. Ап operator may be defined twice only if it takes a 
left argument іп one case and no left argument іп the other, this 
being a criterion CGOL uses when deciding what a particular token in a 
program means. In the above table, the operators "(", "+" and "-" all 
have such dual méanings. The delimiters may appear in arbitrarily 
many definitions, and arbitrarily often in each. However, note that a 
delimiter's binding power is set to the minimum of its previous 
binding power and the right binding power of the operator being 
defined. If thd delimiter has already been defined to be an operator 
With.a left argument (the term is LED, for LEft Denotation - NUD is 
the case when the left argument is missing, or NUII), and this new 
binding power is less than its old, an error message is given. 


The default binding power is 25 if none is specified, and 
applies to both left and right binding powers. If one binding power 
is given it is the left and right binding powers. If both are given, 
they are respectively the left and right. ones. 


Like LISP, CGOL is a one-pass system. This is so that a user 
can type in a definition and have it take effect immediately. This 
conflicts with the requirement in any system offering sophisticated 
syntax that it be possiblé to use the syntax of an operator before it 
has been defined. This requirement is nice in general, and essential 
for mutually гесигвіуе function definitions. То get around this 
problem, you may define the syntax of an operator at any time without 
giving its semantics, simply by omitting the body of the define 
command. This is not an elegant solution, and a later version of CGOL 
may deal with this. (А possible solution is to keep around pieces of 
unparsable text until they become parsable, апа then parse them. Even 
more dramatic is the solution of not parsing anything until it is to 
be evaluated, i.e. dropping the unparsabilitü condition from the 
. previous solution.) 


5. EXTENDING CGOL 


It is possible to add to or change the definitions of the 
rules of CGOL (the ones in Section 2). To see examples. of such 
definitions, look under the heading BASE COMPONENT in the file 
AI:PRATT;CGOL >. Given the above table, you should be able to get a 
rough idea of how to write such definitions. : 


тһе meaning of 


e 


infix "«" 20 is "PLUS" 


is as follows. The infix operator "+" is being defined with left and 
right binding power 20. (Had I said "infixr" it would make "+" right 
associative by making its right binding power 19, one less than its 
left.) The translation of "a+b" is then (PLUS А B) . Since the 
argument positions are "standard" for infix operators, the only 
information you аав need to supply is what the LISP function name 
ів, so you say "is "PLUS"" . You don't have to use "is" - if you want 
you can spell it out by saying ["PLUS", left, right) , which is а CGOL 
program to build a list whose three elements are the atom "PLUS", the 
left hand argument and the right hand argument. Notice the use of 
this technique when defining , 


infixr "&" 1 ["PROG2", nil, left, right) 


“Ме can't say 'is “PROG2"’ because that uould mean '[*PROC2", left, 
right]'. i i 


6. COMPILATION ' 


| Temporarily there is some awkwardness їп compiling which will 
hopefully go away soon. In the meantime, a CGOL program is compiled 
by saying i i : 


пакер «filename» i i . i 


to CGOL, using the same autas as for the other file manipulating 
commands (uread, etc). CGOL will then produce a file with the same 
FNL (if using MIT's ITS) and with FN2 = LISP , апа will return the 
area the file is on, e.g. (DSK SMITH). This file may then be compiled 
-in the usual way. This also provides a convenient way of exporting 
CGOL programs to sites without CGOL - just send them the LISP 
translation. 


Sometime it will be possible to have one’s CGOL file compiled 
by NCOMPL without any action on your part provided your file begins 
With the incantation (CGOL). See the discussion at the end of section 
1.3. ) 


27. IMPLEMENTATION 


CGOL is not resource-hungry. It consumes about 1K of binary 
program space and 1.5K of list space. It uses the LISP reader for 
lexical analysis, and so loses no more time on this account than does 
standard notation. The parser executes about ten instructions per 
lexical item, a negligible amount. . The semantics of most CGOL 
operators is trivial enough that they take little time to execute. 
Unlike systems based on BNF grammars, you can extend the CGOL notation 
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on-line with none of the overhead associated with systems that have to 
consider the whole grammar before admitting a new rule. 


8. COMPARISON WITH MLISP 
4 
Тһе similarities between CGOL and Smith and Enea’s MLISP are: 


а» the use ‘of ALGOL-like notation for LISP S-expressionej 
tii) the use of numeric operator precedence functions’ to resolve 
association problems; 


Gi the ability to export LISP translations of MLISP/CGOL programs 
' to sites supporting LISP but not MLISP/CGOL. 


The differences are: 


(iy MLISP is a sophisticated programming language offering many 
facilities not appearing in LISP. These facilities are only visible 
to the speaker of MLISP, and vanish if he wants to use them while 
speaking LISP. (Due to the ubiquity of LISP’s oblist, the user can 
get at them from LISP, though they are undocumented and have names 
starting with & to identify them ds sytem names not for general 
consumption.) Assignment to S-expressions is a particularly complex 
' example. In contrast, CGOL offers nothing but an alternative 
notation for things already meant for consumption by LISP users. 
This enables CGOL to be very small, both with respect to its 
implementation and its manual. 


(ii) > MLISP is a system that the user must call from the monitor, 
whereas CGOL is a package that can be loaded into LISP when the 

need arises. Hence a non-CGOL user can read а CGOL file without 
having to commit himself to à CGOL-oriented system when he loads LISP. 
In fact, 4hen the 1/0 details are worked out as in Section 1.3 he пау 
never know that he was reading a.CGOL file. 


.9. KNOWN DIFFERENCES BETWEEN THE MANUAL AND THE IMPLEMENTATION 


a<b<c not implemented. (Only a«b). Similarly for a»b. 
Can't use б0 in the body of "new". Use 
prog(a, b, m, c, go m, d) 


Use ^ for exponentiation i 


Use mod for remainder (not really воя: since the PDP- 18 treats negative 
modul i incorrectly). 


Del imi ters presently get Ibp 8. 


=13+ 
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